home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11818 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.7 KB
  1. Path: herold.franken.de!jhd
  2. Date: 14 Mar 1996 21:23:00 +0100
  3. From: jhd@herold.franken.de (Joachim Durchholz)
  4. Newsgroups: comp.lang.eiffel,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng
  5. Message-ID: <64ss5$3F3RB@herold.franken.de>
  6. References: <1995Jul3.034108.4193@rcmcon.com>
  7.     <3taaha$p8j@ixnews3.ix.netcom.com> <3tap9h$qp3@saba.info.ucla.edu>
  8.     <RMARTIN.96Mar13110714@rcm.oma.com> <4i862r$1evq@saba.info.ucla.edu>
  9. Subject: Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer
  10. X-Newsreader: CrossPoint v3.1
  11.  
  12. jmartin@cs.ucla.edu wrote 14.03.96 on Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer:
  13.  
  14. > No "hacking" is broader than that, it is writing poor code period. It
  15. > is writing low level or obscure code when it is unnecessary because
  16. > you think that its great.
  17.  
  18. Your definition of hacking is much too narrow.
  19.  
  20. Hacking is programming in an elegant way.
  21.  
  22. Stuffing as much logic as possible into a single line of C is one possible  
  23. variant elegance. Such elegance doesn't have any relevance to Software  
  24. Engineering, of course. It is more related to crossword puzzles, Mensa  
  25. riddles, the Obfuscated C Contest and all other sort of intellectual  
  26. challenges. It has no useful purpose beyond itself, and should not be  
  27. taken seriously for serious work. (It would be ridiculous to take this  
  28. type of fun stuff seriously!)
  29.  
  30. But don't confuse these intellectual games with the Real World.
  31.  
  32. Yes, there are hackers that just cannot write clear code. But these  
  33. hackers won't be too famous; either they will do many programs - then  
  34. their reputation will soon break down because their programs don't work;  
  35. or they will spend their time maintaining and adapting their single badly  
  36. designed program, which doesn't allow them to gain much recognition.
  37.  
  38.  
  39. There is one trait among many hackers that will make method gurus uneasy -  
  40. they don't like to be restricted.
  41. This makes C popular among hackers - it gives many benefits of discipline  
  42. (many opportunities for the compiler to do type checking), but allows  
  43. evading the restrictions whenever necessary (type casts).
  44.  
  45. But don't make the mistake that hackers want to have absolute freedom. If  
  46. they wanted that, they'd program in assembler.
  47. Oops, I forgot machine code. They'd use machine code and make use of the  
  48. instruction encoding for the program's constants.
  49. And now look how many hackers actually do that. I think there are a few  
  50. that do, but I don't know any of them personally, and I have never seen  
  51. such code, so this type must be extremely rare.
  52.  
  53. Why? Because hackers would trade freedom for programming efficiency any  
  54. day.
  55.  
  56. Remember the argument that subroutine calls slow down programs.  
  57. Subroutines have won because they made programming much easier and faster.
  58.  
  59. The same will hold for OO programming. If OO programming makes hackers  
  60. program faster and better, they will use it. If it doesn't, they won't use  
  61. it (and frankly, I think OO would deserve it - not that I think this will  
  62. happen).
  63.  
  64.  
  65. I haven't said a word of design phase vs. programming phase. And my  
  66. impression is indeed that a hacker doesn't want to waste time on design  
  67. when he could use to build working programs. But that is more a question  
  68. of the point of view; the hackers that build large systems do design in an  
  69. informal way, and they usually don't document it. Nevertheless all larger  
  70. programs done by hackers have a design.
  71. And on the design side, I have seen hours spent on design meetings, put  
  72. the results into specifications - only to discover two weeks later that  
  73. the specifications were utter sh*t. Such incidents don't exactly encourage  
  74. hackers to spend time on design.
  75.  
  76.  
  77.  
  78. -Joachim
  79.  
  80. --
  81. Im speaking for myself here.
  82. ## CrossPoint v3.1 ##
  83.